Add Dockerfile auto-discovery when scanning is enabled by dc-larsen · Pull Request #19 · SocketDev/socket-basics

dc-larsen · 2026-01-06T22:07:08Z

Problem

Customers currently need to manually specify Dockerfile paths in their config:

- uses: SocketDev/socket-basics@1.0.25
  with:
    dockerfile_scanning_enabled: 'true'
    dockerfiles: 'Dockerfile,docker/Dockerfile.prod,services/api/Dockerfile'

This is tedious and error-prone, especially across multiple repos where Dockerfiles may be in different locations.

Solution

Auto-discover Dockerfiles when scanning is enabled but no explicit paths are configured.

Before: Customer must know and list every Dockerfile path
After: Just enable scanning, Socket Basics finds them automatically

- uses: SocketDev/socket-basics@1.0.25
  with:
    dockerfile_scanning_enabled: 'true'
    # That's it - Dockerfiles are found automatically

Implementation

Added _discover_dockerfiles() method to the Trivy connector that:

Walks the workspace directory tree using os.walk()
Matches files against common Dockerfile naming patterns
Excludes directories that typically contain third-party or test code
Returns relative paths for discovered Dockerfiles

Discovery Patterns

Pattern	Examples
Exact match	`Dockerfile`
Prefix match	`Dockerfile.prod`, `Dockerfile.dev`, `Dockerfile.test`
Extension match	`app.dockerfile`, `backend.dockerfile`

Excluded Directories

Directories are excluded case-insensitively to avoid false positives:

Category	Directories
Dependencies	`node_modules`, `vendor`
Version control	`.git`, `.svn`, `.hg`
Test directories	`test`, `tests`, `testing`, `__tests__`, `spec`, `specs`
Test fixtures	`fixture`, `fixtures`, `testdata`, `test_data`
Examples	`example`, `examples`, `sample`, `samples`
Mocks	`mock`, `mocks`
Build artifacts	`dist`, `build`, `out`, `target`
Virtual envs	`venv`, `.venv`, `env`, `.env`
Caches	`.cache`, `.tox`, `.nox`, `.pytest_cache`
Socket Basics fixtures	`app_tests`

Behavior

Scenario	Result
`dockerfiles` explicitly set	Uses explicit config (no change)
`dockerfiles` empty + scanning enabled	Auto-discovers Dockerfiles
`dockerfiles` empty + scanning disabled	Skips scanning (no change)
No Dockerfiles found	Logs message, skips scanning

Test Coverage

15 unit tests covering all discovery and exclusion scenarios:

Running Dockerfile auto-discovery tests...

  ✓ discovers_dockerfile_at_root
  ✓ discovers_dockerfile_in_subdirectory
  ✓ discovers_dockerfile_with_suffix
  ✓ discovers_dockerfile_extension
  ✓ excludes_node_modules
  ✓ excludes_vendor_directory
  ✓ excludes_test_directories
  ✓ excludes_fixture_directories
  ✓ excludes_example_directories
  ✓ excludes_build_directories
  ✓ excludes_app_tests_directory
  ✓ discovers_multiple_dockerfiles
  ✓ empty_workspace_returns_empty_list
  ✓ no_dockerfiles_returns_empty_list
  ✓ case_insensitive_exclusions

Results: 15 passed, 0 failed

Test Details

Test	What it validates
`discovers_dockerfile_at_root`	Finds `Dockerfile` in workspace root
`discovers_dockerfile_in_subdirectory`	Finds `docker/Dockerfile` nested paths
`discovers_dockerfile_with_suffix`	Finds `Dockerfile.prod`, `Dockerfile.dev`
`discovers_dockerfile_extension`	Finds `app.dockerfile`, `backend.dockerfile`
`excludes_node_modules`	Skips `node_modules/**/Dockerfile`
`excludes_vendor_directory`	Skips `vendor/**/Dockerfile`
`excludes_test_directories`	Skips `test/`, `tests/`, `testing/`, `__tests__/`
`excludes_fixture_directories`	Skips `fixture/`, `fixtures/`, `testdata/`
`excludes_example_directories`	Skips `example/`, `examples/`, `sample/`, `samples/`
`excludes_build_directories`	Skips `dist/`, `build/`, `out/`, `target/`
`excludes_app_tests_directory`	Skips Socket Basics test fixtures
`discovers_multiple_dockerfiles`	Finds 4 Dockerfiles across different locations
`empty_workspace_returns_empty_list`	Handles empty workspace gracefully
`no_dockerfiles_returns_empty_list`	Returns `[]` when no Dockerfiles exist
`case_insensitive_exclusions`	`Node_Modules`, `VENDOR`, `Tests` all excluded

Files Changed

socket_basics/core/connector/trivy/trivy.py - Added _discover_dockerfiles() method and integration
tests/test_dockerfile_discovery.py - Pytest test suite (for future use with Python 3.10+)
tests/run_discovery_tests.py - Standalone test runner (works with any Python 3.x)

Example Log Output

INFO - Auto-discovered 3 Dockerfile(s): Dockerfile, docker/Dockerfile.prod, services/api/Dockerfile
INFO - Running Trivy Dockerfile scanning
INFO - Running: trivy config --format json --output /tmp/xxx.json /workspace/Dockerfile

🤖 Generated with Claude Code

When Dockerfile scanning is enabled but no explicit `dockerfiles` config is provided, automatically search the workspace for Dockerfiles instead of skipping the scan entirely. Discovery patterns: - Dockerfile (exact match) - Dockerfile.* (e.g., Dockerfile.prod, Dockerfile.dev) - *.dockerfile (e.g., app.dockerfile) Excluded directories to avoid false positives: - node_modules, vendor, .git - test, tests, testing, __tests__, spec, specs - fixture, fixtures, testdata, test_data - example, examples, sample, samples - dist, build, out, target - venv, .venv, env, .env - app_tests (Socket Basics test fixtures) This improves the customer experience by eliminating the need to manually specify Dockerfile paths in each repo, while still respecting explicit configuration when provided. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

ahmadnassri · 2026-01-07T00:12:54Z

socket_basics/core/connector/trivy/trivy.py

+            return []
+
+        # Directories to exclude from search
+        exclude_dirs = {


should exclude dirs based on content of .gitignore

Good point. Using .gitignore would make exclusions project-specific rather than hardcoded.

A few considerations:

Parsing complexity - .gitignore supports wildcards, negations (!keep.txt), directory-only patterns, and nested files. Would need a library like pathspec to handle it correctly.

Different intent - .gitignore defines what Git shouldn't track, not necessarily what shouldn't be scanned. A Dockerfile in an ignored test fixture could still have real security issues worth catching.

Missing/minimal .gitignore - Not all repos have one, so we'd still need a fallback list.

For this PR, the hardcoded list provides predictable baseline behavior. Could add .gitignore support as a follow-up with a flag like respect_gitignore: true for users who want it.

Open to discussing if you feel strongly this should block the PR.

- Dockerfile with simple Python app (has USER root finding) - GitHub Actions workflow with two test cases: - Toggle OFF: No dockerfiles input - Toggle ON: dockerfiles=Dockerfile - README explaining test cases Tests behavior from SocketDev/socket-basics#19 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

dc-larsen · 2026-01-16T19:17:24Z

Smoke Test Results

Ran a live CI test to verify the Dockerfile scanning toggle behavior.

Test Repo: dc-larsen/socket-basics-smoke-test
Workflow Run: #21077917665

Test 1: Toggle OFF (no `dockerfiles` input)

Input: No dockerfiles parameter
Expected: Trivy connector not loaded, no Dockerfile scanning

Result: ✅ PASS

Starting security scanning with dynamic connectors...
Results saved to: /github/workspace/.socket.facts.json
Scan completed!
Components analyzed: 0
Total alerts: 0

Note: Trivy connector was NOT loaded at all. The Dockerfile in the repo was ignored.

Test 2: Toggle ON (`dockerfiles: Dockerfile`)

Input: dockerfiles: "Dockerfile"
Expected: Trivy connector loaded, Dockerfile scanned

Result: ✅ PASS

Successfully loaded connector: trivy
Running Trivy Dockerfile scanning
Running: trivy config --format json --output /tmp/tmptfc38bze.json Dockerfile
Components analyzed: 1
Total alerts: 2
Found 1 high/critical severity issues

The job shows as "failed" because it found a USER root security finding (expected behavior).

Conclusion

The toggle behavior works as designed:

Toggle OFF: Even with a Dockerfile present, no scanning occurs
Toggle ON: Trivy loads and scans the Dockerfile, reporting findings

dc-larsen · 2026-01-31T20:59:33Z

Closing in favor of native GitHub Action flow for Dockerfile discovery. See Doug's recommendation from Jan 29 - this approach is more portable and doesn't require changes to Socket Basics.

dc-larsen requested a review from a team as a code owner January 6, 2026 22:07

ahmadnassri reviewed Jan 7, 2026

View reviewed changes

dc-larsen closed this Jan 31, 2026

dc-larsen mentioned this pull request Feb 4, 2026

docs: add Dockerfile auto-discovery workflow pattern #25

Merged

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Dockerfile auto-discovery when scanning is enabled#19

Add Dockerfile auto-discovery when scanning is enabled#19
dc-larsen wants to merge 1 commit intomainfrom
feature/dockerfile-auto-discovery

dc-larsen commented Jan 6, 2026 •

edited

Loading

Uh oh!

ahmadnassri Jan 7, 2026

Uh oh!

dc-larsen Jan 23, 2026

Uh oh!

dc-larsen commented Jan 16, 2026

Uh oh!

dc-larsen commented Jan 31, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

dc-larsen commented Jan 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Solution

Implementation

Discovery Patterns

Excluded Directories

Behavior

Test Coverage

Test Details

Files Changed

Example Log Output

Uh oh!

ahmadnassri Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

dc-larsen Jan 23, 2026

Choose a reason for hiding this comment

Uh oh!

dc-larsen commented Jan 16, 2026

Smoke Test Results

Test 1: Toggle OFF (no dockerfiles input)

Test 2: Toggle ON (dockerfiles: Dockerfile)

Conclusion

Uh oh!

dc-larsen commented Jan 31, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

dc-larsen commented Jan 6, 2026 •

edited

Loading

Test 1: Toggle OFF (no `dockerfiles` input)

Test 2: Toggle ON (`dockerfiles: Dockerfile`)